REMARKS 



Applicant is in receipt of the Office Action mailed January 11, 2007. Claims 19- 
25 have been cancelled. Claims 1-18 have been amended. New claims 26-28 have been 
added. Thus, claims 1-18, and 26-28 are pending in the case. Reconsideration of the 
present case is earnestly requested in light of the following remarks. 

Section 101 Rejections 

Claims 1-25 were rejected under 35 U.S.C. 101 for non-statutory subject matter. 
Applicant has amended "carrier medium" claims 1-18 as indicated above to refer instead 
to a "computer accessible memory medium". Applicant has cancelled "carrier medium" 
claims 22-23, as well as non-statutory claims 19-21 and 24-25, thus rendering their 
rejections moot. 

Applicant thus respectfully requests removal of the 101 rejection of claims 1-18. 

Section 102 Rejections 

Claims 1-10, 12-13, and 15-25 were rejected under 35 U.S.C. 102(e) as being 
anticipated by Zink et al (US 6,738,964, "Zink"). Applicant respectfully disagrees. 
Claims 19-25 have been cancelled, thus rendering the rejection of these claim moot. 

As the Examiner is certainly aware, anticipation requires the presence in a single 
prior art reference disclosure of each and every element of the claimed invention, 
arranged as in the claim. Lindemann Maschinenfabrik GmbH v. American Hoist & 
Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical invention must be 
shown in as complete detail as is contained in the claims. Richardson v. Suzuki Motor 
Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

Amended claim 1 recites: 

1 . A computer accessible memory medium comprising program instructions, 
wherein the program instructions are executable by a processor to implement: 

displaying a display window comprising a plurality of graphical program nodes 
for use in a graphical program; 
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wherein the plurality of graphical program nodes comprise a hierarchy of 
graphical program nodes, wherein said hierarchy comprises: 

a first plurality of function nodes displayed in the display window, 
wherein each function node corresponds to a respective functionality; and 

a second plurality of property nodes displayed in the display window, 
wherein each property node corresponds to a respective one of at least a subset of the 
plurality of function nodes, wherein each property node is displayed proximate to said 
respective one of the at least a subset of the plurality of function nodes. 

Nowhere does Zink teach or suggest displaying a display window comprising a 
plurality of graphical program nodes for use in a graphical program, as recited in 
claim 1 . 

In asserting that Zink discloses this feature, the Office Action cites Figure 6, 
elements 602 and 603, and related text. Applicant respectfully notes that per Zink, 602 is 
a menu bar that "provides access to a set of drop-down menus that provide many useful 
functions like adding components to the drawing, saving the drawing, and configuring the 
target hardware." Zink's mentioned drop-down menu that provides a function for adding 
components to the drawing is not equivalent to displaying a display window that includes 
a plurality of graphical program nodes for use in a graphical program. 

According to Zink, "Tool bar 603 provides a row of icon-buttons to permit rapid 
access to functions that are most commonly used. In this example, the tool bar functions 
from left to right are: new drawing, open a file, save the drawing, cut, copy, paste, add a 
component to the drawing, build, run, stop, reset the target hardware, add a probe, add an 
audio probe, and lastly, turn on the data viewer. It is common to provide more than one 
tool bar." {emphasis added) 

Applicant respectfully submits that providing a button on a toolbar for "adding a 
component" in no way teaches displaying a display window that includes a plurality of 
graphical program nodes for use in a graphical program. For example, Applicant notes 
that in each of these examples (602, 603), no palette of function nodes is presented, but 
rather, a means for adding a component is referred to (specifically, a menu or toolbar 
button), but what exactly this "means" entails is not disclosed. For example, a user might 
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invoke a file browser (via the menu or button) to browse directories that include files for 
the desired functionality or components. However, Zink is silent as to what activation of 
the menu item or button might invoke, and makes no mention of displaying a plurality of 
graphical program nodes for use in a graphical program in a display window. 
Thus, Zink fails to teach or suggest this feature of claim 1 . 

Zink also fails to teach or suggest wherein the plurality of graphical program 
nodes comprise a hierarchy of graphical program nodes, wherein said hierarchy 
comprises: a first plurality of function nodes displayed in the display window, 
wherein each function node corresponds to a respective functionality; and a second 
plurality of property nodes displayed in the display window, wherein each property 
node corresponds to a respective one of at least a subset of the plurality of function 
nodes, wherein each property node is displayed proximate to said respective one of 
the at least a subset of the plurality of function nodes, as recited in claim 1 . 

In asserting that Zink teaches wherein the plurality of graphical program 
nodes comprise a hierarchy of graphical program nodes, wherein said hierarchy 
comprises: a first plurality of function nodes displayed in the display window, the 

Office Action cites 603 and 603 of Figure 6 and associated text, e.g., col.4: 12-23, and 
col. 11:52-60. 

As discussed above, 602 and 603 of Figure 6 (and their related descriptions in 
col.4: 12-23) in no way teach or suggest displaying in a display window a plurality of 
function nodes for use in a graphical program. Moreover, col. 11:52-60 describes several 
different types of components can be used in a drawing, e.g., software components, such 
as software designed to perform a pre-defined task (e.g. a sine wave signal source), as 
well as other types of components, such as hardware components, platform components, 
framework components, annotation components, and intrinsic components. Nowhere 
does the cited text (or Zink in general) teach or suggest this claimed feature. 

In asserting that Zink teaches a second plurality of property nodes displayed in 
the display window, wherein each property node corresponds to a respective one of 
at least a subset of the plurality of function nodes, wherein each property node is 
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displayed proximate to said respective one of the at least a subset of the plurality of 
function nodes, the Office Action cites col. 11:60-67. Applicant respectfully notes that 
this text describes platform components that contain information about the target 
hardware where the project's executable code will be "run", e.g., the operating system or 
kernel. Again, nowhere does this text discuss such property nodes being displayed in a 
display window, where each property node corresponds to a respective one of at least a 
subset of the plurality of function nodes, and where each property node is displayed 
proximate to the respective one of the at least a subset of the plurality of function nodes. 

Thus, Applicant respectfully submits that Zink fails to teach or suggest all the 
features and limitations of claim 1 , and so claim 1 and those claims dependent therefrom 
are patentably distinct and non-obvious over the cited art, and art thus allowable. 

Applicant respectfully submits that independent claims 27 and 28 include similar 
limitations as claim 1, and so the above arguments apply with equal force to these claims. 
Thus, for at least the reasons provided above, Applicant submits that claims 27 and 28, 
and those claims respectively dependent therefrom, are patentably distinct and non- 
obvious over the cited art, and art thus allowable. 

Removal of the section 102 rejection of claims 1-10, 12-13, and 15-18 is 
respectfully requested. 

Section 103 Rejections 

Claims 11 and 14 were rejected under 35 U.S.C. 103(a) as being unpatentable 
over Zink in view of Kellerman et al. (US 6,750,887 Bl, "Kellerman"). Applicant 
respectfully disagrees. 

As the Examiner is aware, if an independent claim is nonobvious under 35 U.S.C. 
103, then any claim depending therefrom is nonobvious. In re Fine, 837 F.2d 1071, 5 
USPQ2d 1596 (Fed. Cir. 1988). Because independent claim 1 has been shown above to 
be patentably distinct and non-obvious, and thus allowable, dependent claims 11 and 14 
are similarly patentably distinct and non-obvious, and thus allowable. 

Additionally, Applicant respectfully submits that neither Zink nor Kellerman 
discloses all the features of these claims. For example, the Office Action asserts that 
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Zink teaches wherein, in each property node being displayed proximate to the 
respective one of the at least a subset of the plurality of function nodes, each 
property node is displayed in a common row with the respective one of the at least a 
subset of the plurality of function nodes, as recited in claim 14, citing Figure 13:1502 
and associated text, col.l2:52-13:7, col.l3:57-col.l4:l, col.l5:45-50, and Figure 17B 
with associated text. 

Applicant has reviewed the cited portions of Zink closely, and can find no 
description of these claimed features. For example, Figure 13:1502 and associated text 
discloses annotation components for annotating components in Zink's display, such as 
text boxes, dotted lines, labels, etc. More specifically, per Figure 13 and col.l2:52-13:7, 
element 1502 refers to a rectangle (shown in Figure 13) that the user may employ to 
indicate that a group of components has some common characteristic, and nowhere 
discloses a plurality of property nodes, each displayed proximate to a respective 
(corresponding) function node in a common row. 

Col.l3:57-col.l4:l discusses user access to property settings for components, and 
discloses various means for providing this access, including "list-boxes (very similar to 
FIG. 8C), icon-based graphical user interfaces, dedicated property dialog windows, and 
via "wizards" that prompt the user for performance-related information and then process 
the user inputs to determine actual property settings". Again, nowhere does this text (or 
the Figures) disclose the display of property nodes proximate to corresponding function 
nodes in a common row as claimed. 

Col. 15:45-50 discusses the user setting properties of each block on a drawing via 
a property dialog window as shown in Figure 17B, and nowhere describes display of 
property nodes proximate to corresponding function nodes in a common row as claimed. 

Thus, Applicant respectfully submits that the cited portions of Zink, and Zink in 
general, fail to disclose these features of claim 14. 

The Examiner admits that Zink fails to disclose wherein, in each property node 
being displayed proximate to the respective one of the at least a subset of the 
plurality of function nodes, each property node is displayed in a common column 
with the respective one of the at least a subset of the plurality of function nodes, as 
recited in claim 14, but asserts that Kellerman remedies this admitted deficiency of Zink. 
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Applicant disagrees, noting that the cited col.4:8-50 (and Figure 1) of Kellerman is 
directed to a GUI layout, specifically, rows and columns of GUI components, "such as 
text labels, buttons, combo boxes or text fields," etc. Applicant notes that these GUI 
components are not graphical program nodes, and more specifically are not function 
nodes and corresponding property nodes. Nowhere does the cited text, Figures, or 
Kellerman in general, disclose a plurality of property nodes, each displayed proximate to 
a respective (corresponding) function node in a common column. 

Thus, Applicant respectfully submits that Kellerman fails to teach or suggest these 
features of claim 14. 

Nor do Zink or Kellerman teach or suggest displaying primary and secondary 
function nodes in the display window in respective groups, where the primary set of 
function nodes is displayed in a first column in the display window and the secondary set 
of function nodes is displayed in a second column in the display window, as recited in 
claim 1 1 . 

Finally, Applicant submits that Zink and Kellerman are not properly combinable 
to make a prima facie case of obviousness, for at least the reason that a proper motivation 
to combine has not been presented. Applicant notes that the suggest motivation to 
combine: "to address the problem of laying out (i.e., organizing and displaying) visual 
components (graphical nodes) of a GUI in a pleasing arrangement with minimum 
developer effort" (Kellerman col. 3:35-52), is not germane to Applicant's invention as 
claimed. For example, Applicant submits that Kellerman's visual GUI components are 
not equivalent to Applicant's graphical program nodes, which are nodes, specifically, 
function nodes and property nodes, for use in a graphical program, not GUI elements. 

Thus, Zink and Kellerman are not properly combinable to make a prima facie case 
of obviousness. Moreover, even were Zink and Kellerman properly combinable, which 
Applicant argues they are not, the resulting combination would still not produce 
Applicant's invention as claimed, as argued at length above. 

Thus, for at least the reasons provided above, Applicant submits that Zink and 
Kellerman, taken singly or in combination, fail to teach or suggest all the features and 
limitations of claims 11 and 14, and so claims 11 and 14, and those claims respectively 
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dependent therefrom, are patentably distinct and non-obvious over the cited art, and art 
thus allowable. 

Removal of the section 103 rejection of these claims is respectfully requested. 

Applicant also asserts that numerous ones of the dependent claims recite further 
distinctions over the cited art. However, since the independent claims have been shown 
to be patentably distinct, a further discussion of the dependent claims is not necessary at 
this time. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 

If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the 
above-referenced application(s) from becoming abandoned, Applicant(s) hereby petition 
for such extensions. The Commissioner is hereby authorized to charge any fees which 
may be required or credit any overpayment to Meyertons, Hood, Kivlin, Kowert & 
GoetzelP.C, Deposit Account No. 50-1505/5150-81 100/JCH. 

Also filed herewith are the following items: 
I I Request for Continued Examination 
I I Terminal Disclaimer 

O Power of Attorney By Assignee and Revocation of Previous Powers 
O Notice of Change of Address 
□ Other: 

Respectfully submitted, 

/Jeffrey C. Hood/ 

Jeffrey C. Hood, Reg. #35198 
ATTORNEY FOR APPLICANT(S) 

Meyertons, Hood, Kivlin, Kowert & Goetzel PC 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: March 9, 2007 JCH/MSW 



15 



